As more and more applications, services, and data have moved to cloud computing models, security of data and accounts has become a paramount issue and significant challenge requiring new and unique solutions and policies.
As a specific example, in traditional computing environments, e.g., non-cloud computing environments, when a security vulnerability, or other software application feature, needed to be addressed or upgraded, additional code, known as a “patch,” was provided to the physical hardware-based computing system, i.e. server, providing the software application and this patch code was then incorporated in the software running on the hardware computing system. This type of “fix” was acceptable, and efficient, in a hardware-based server environment where the replacement of the hardware computing system server itself was not an economically viable option.
However, in a cloud computing environment, the “computing systems/servers” are actually virtual machines, known as instances, which are not themselves hardware systems but are instead software-based entities which operate like traditional physical hardware-based computing systems/servers.
One of the many advantages associated with virtual machine instances of computing system/servers is that these instances can be generated and terminated at will without the need for replacing physical hardware. Consequently, when a new software vulnerability solution, or other fix is required, instead of implementing a patch on a physical hardware system, as was done traditionally to repair a vulnerability or provide a fix, the entire virtual computing system/server instance can be terminated and new computing system/server instances can be generated or “spun up” to replace the terminated instances, with the new instances being based on, or running, the updated repaired or fixed software.
In particular, a given computing system/server virtual machine instance, hereafter referred to as simply an “instance,” is typically created in a cloud computing environment using an instance creation template. As used herein, the term “instance creation template” is used to denote a special type of virtual appliance that is used to create a virtual machine (instance) within a cloud computing environment. A specific illustrative example of an instance creation template is an Amazon Machine Image (AMI). An AMI is a special type of instance creation template that is a virtual appliance used to create a virtual machine within the Amazon Elastic Compute Cloud (“EC2”). An AMI serves as the basic unit of deployment for services delivered using EC2.
As noted above, in a cloud computing environment, one way to correct a vulnerability, or otherwise update or correct, a system/application is to issue a new instance creation template which incorporates the desired change/fix. In an AWS environment, this means issuing new or updated AMIs. Consequently, in a cloud computing environment, whenever a new instance creation template, referred to herein as a new base instance creation template, is generated and made available, it is highly desirable that all instances associated with an account or application that were created using previously generated base instance creation templates be terminated and new instances, based on the new instance creation template, be created/launched to replace the old instances based on the old instance creation template. Then the instances based on the new instance creation template can be used to service the account and implement and/or offer the application associated with the account.
The process of terminating old instances associated with a given account or application and replacing those instances with new instances is referred to herein as “re-stacking.”
As can be seen from the discussion above, the re-stacking of instances associated with a given account or application, and policies associated with the re-stacking of instances, is a significant indicator of the overall security and efficiency of the account and associated application. Indeed, were an account holder, application provider, or cloud computing system environment provider given the capability to easily identify and evaluate the re-stacking policies associated with a given account and application, then significant information regarding the security of the account, application, and even the entire cloud computing environment, could be readily recognized.
However, the mere act of re-stacking of instances associated with a given account or application does not necessarily ensure that security vulnerabilities are eliminated, or even reduced. This is because, individual instances, even newly re-stacked instances, are only as secure as the actual instance creation template/AMI upon which they are based. In short, if instance creation templates/AMIs with security vulnerabilities are used as new base re-stack instance creation templates/AMIs, then the re-stack can result in no reduction in security vulnerabilities, and even potentially in new, or more, security vulnerabilities being introduced. Likewise, if old base instance creation templates/AMIs are relatively secure, i.e., have few, or no security vulnerabilities, then the use of these “outdated” instance creation templates/AMIs for re-stacking may result in no additional security vulnerabilities being introduced.
The situation is made even more complicated by the fact that a given account holder/application provider may generate and implement their own customized instance creation templates/AMIs. While these customized instance creation templates/AMIs typically represent only minor changes made to base instance creation templates/AMIs, they can include potential security vulnerabilities not necessarily present in the instance creation templates/AMIs. In short, the customized instance creation templates/AMIs can introduce customized security vulnerabilities. Consequently, these customized instance creation templates/AMIs further complicate any attempt at security vulnerability analysis.
Therefore, despite the value of an efficient and effective visualization of re-stacking policies associated with a given account, and the value of determining the security vulnerability of instance creation templates used in the re-stacking process, there is currently no mechanism or system available to effectively and efficiently identify and evaluate the re-stacking policies associated with a given account or application or the security vulnerability of the re-stacking policies used. This is largely due to the fact that many account holders, application providers, and cloud computing system providers have yet to fully recognize the significance of re-stacking policy analysis and that the amounts of data that must be analyzed for even a modest account or application offering is potentially overwhelming. Consequently, there is currently no algorithm or process for obtaining this re-stacking data and instance creation template security vulnerability data, much less processing it in a manner that produces a useful analysis tool.
Therefore, there is a long standing technical need in the cloud computing arts for providing a method and system to identify and evaluate re-stacking policies and the security vulnerabilities associated with those re-stacking policies.